AWS Directory Service คืออะไร? การแนะนำฟังก์ชันล่าสุดของ AWS ในปี 2023
AWS Directory Service คืออะไร
AWS Directory Service เป็นบริการ AWS ที่เป็น Managed service สำหรับ "Active Directory" ของ Microsoft Windows
เมื่อพูดถึงคำว่า "Directory service" จะหมายถึง directory service ที่เกี่ยวข้องทั้งหมดรวมไปถึง Active Directory ด้วย
แต่ทว่า สิ่งที่ AWS Directory Service ให้บริการไม่ใช่ directory service ทั้งหมด แต่เป็นหมวด "Active Directory"
ถ้าเปรียบก็เหมือน "Active Directory" เป็น "ชื่อแบรนด์สินค้า" ที่ติดอยู่บนผลิตภัณฑ์ที่เกี่ยวข้องกับ Management ID และ การรับรองจาก Microsoft โดยผลิตภัณฑ์ที่ให้บริการ directory service ใน Active Directory ก็คือ "Active Directory Domain Service (AD DS)"
อาจจะไม่ผิดนักหากจะกล่าวว่า AWS Directory Service เป็น Managed service ของ Active Directory Domain Service (AD DS)
※ ประวัติโดยคร่าวๆ ในยุค Windows Server 2000 Active Directory ได้รับการเปิดตัวในฐานะรุ่นต่อยอดจาก "Windows NT Domain" และ "directory service ที่สนับสนุน LDAP" หลังจากนั้น เมื่อถึงยุค Windows Server 2008 ฟังก์ชันอื่นๆนอกเหนือจาก directory service ก็ได้ถูกเพิ่มเข้ามาใน Active Directory ซึ่งทำให้ directory service ดั้งเดิมถูกเรียกว่า "Active Directory Domain Service (AD DS)"
โดยบริการที่เพิ่มเข้ามาในช่วงเวลานี้ อย่างเช่น "Active Directory Federation Service (AD FS)" และ "Active Directory Certificate Service (AD CS)" เป็นต้น
การใช้งาน AWS Directory Service
อาจมีหลายคนสงสัยว่า "ควรใช้บริการ AWS Directory Service ในตอนไหน"
มีหลายสถานการณ์ในการใช้งาน AWS Directory Service แต่จะมีการใช้งานหลักๆอยู่ 3 ข้อต่อไปนี้
- การจัดการ Server/client และการยืนยันผู้ใช้งานในสภาพแวดล้อมของ Windows
- การจัดการผู้ใช้งาน และการยืนยันในการใช้บริการ AWS
- การยืนยันผู้ใช้งานในการลงชื่อเข้าใช้ AWS
การจัดการ Server/client และการยืนยันผู้ใช้งานในสภาพแวดล้อม Windows
เป็นวิธีการใช้งานแบบ "ให้ Windows server/client เข้าร่วมใน domain" และ "ยืนยันผู้ใช้งานด้วย domain"
ปัจจุบัน มีรูปแบบดำเนินการด้วย การเข้าร่วม domain หรือ ยืนยันผู้ใช้งานบน AWS (EC2 instance เป็นต้น) และยังสามารถเข้าร่วมกับ domain และทำการยืนยันผู้ใช้งานจาก on-premises ได้อีกด้วย (แน่นอนว่าต้องมีการเชื่อมต่อกับ on-premises ด้วยบริการ Direct Connect,Site-to-site VPN โดยผู้ใช้งาน/Client ที่ได้รับการยืนยันจะสามารถเข้าถึง AWS Directory Service ได้)
และถึงจะระบุว่าเป็น "สภาพแวดล้อมของ Windows" แต่ Linux และ macOS เองก็ก็รองรับการยืนยันผู้ใช้ และ การจัดการเซิร์ฟเวอร์/ไคลเอ็นต์ได้เช่นกัน (ในกรณีนี้ จะใช้ Samba client ที่ติดตั้งเพิ่ม หรือมากับ OS อยู่แล้ว)
การยืนยัน,จัดการผู้ใช้งานเมื่อลงชื่อเข้าใช้ AWS
สามารถใช้ AWS Directory Service ในการยืนยันและจัดการผู้ใช้งานที่ใช้บริการ AWS ได้
โดยฟังก์ชั่นนี้จะรองรับบางบริการของ AWS ซึ่งอาจจะไม่ครอบคลุมบริการทั้งหมด
- Amazon Chime
- Amazon Connect
- Amazon FSx for Windows File Server
- Amazon QuickSight
- Amazon RDS/Aurora
- Amazon WorkDocs
- Amazon WorkMail
- Amazon WorkSpaces
- AWS Client VPN
- AWS Transfer Family
และความสัมพันธ์กับ AWS Directory Service จะแตกต่างกันไปตามประเภทของบริการ AWS ดังนี้
- AWS Directory Service สามารถเลือก วิธีจัดการเฉพาะบริการ(ชื่อผู้ใช้งานและรหัสผ่านฯ)เป็นรูปแบบการจัดการผู้ใช้งานได้
- ตัวอย่าง： Amazon Connect、Amazon RDS เป็นต้น
- การจัดการผู้ใช้งานด้วย AWS Directory Service
- ตัวอย่าง： Amazon WorkSpaces เป็นต้น
นอกจากนี้ เนื่องจากกลไกการจัดการผู้ใช้งานและวิธีการดำเนินการที่เชื่อมโยงกับ AWS Directory Service จะแตกต่างกันไปในแต่ละบริการของ AWS จึงควรตรวจสอบรายละเอียดเพิ่มเติมในเอกสารของแต่ละบริการของ AWS
ในแต่ละ "directory type" ที่จะอธิบายในภายหลังนี้ บางประเภทรองรับกับบริการเหล่านี้ของ AWS และก็มีบางประเภทที่ไม่รองรับ รายละเอียดต่างๆจะมีอธิบายไว้ในบท "การเชื่อมโยงกับบริการของ AWS"
การยืนยันผู้ใช้งานในการลงชื่อเข้าใช้ AWS
สามารถลงชื่อเข้าใช้ AWS Management Console ด้วยการยืนยันผู้ใช้งานผ่าน AWS Directory Service แทนการใช้ IAM users ได้
ในการใช้การยืนยันผู้ใช้งานโดย AWS Directory Service จำเป็นต้อง "เปิดใช้งาน" ฟังก์ชันดังกล่าวผ่าน Management Console ของ AWS Directory Service ก่อน
และด้วยการกำหนด IAM Role ให้แก่ AWS Directory Service Group, User จะทำให้สามารถตั้งค่าสิทธิ์ในการเข้าถึงทรัพยากร AWS บน Management Console ตามผู้ใช้งานที่ลงชื่อเข้าใช้ได้
และในสภาพแวดล้อมที่จัดการหลายบัญชีของ AWS โดยใช้ AWS Organizations เมื่อทำการเชื่อมโยง AWS Single Sign-On (SSO) กับ AWS Directory Service ทำให้สามารถลงชื่อเข้าใช้ AWS Management Console ด้วยการยืนยันผู้ใช้งานด้วย AWS Directory Service ได้
นอกจากการลงชื่อเข้าใช้ไปยัง AWS Management Console แล้ว ยังรองรับ SSO สำหรับการใช้งานร่วมกับแอปพลิเคชันจาก AWS หรือ บริษัทอื่นๆที่สามารถใช้การรับรองผู้ใช้งานโดย AWS Directory Service นี้ได้เช่นกัน
เกี่ยวกับ directory type
AWS directory Service มี "directory type" ที่มีคุณสมบัติแตกต่างด้วยกันอยู่ 3 ประเภท
- AWS Managed Microsoft AD
- Simple AD
- AD Connector
โดยจะอธิบายลักษณะของ directory type แต่ละประเภทดังนี้ครับ
AWS Managed Microsoft AD
"AWS Managed Microsoft AD" ก็ตามชื่อเลยคือให้บริการ "Microsoft Active Directory" เป็น managed service. ซึ่งภายในจะทำงานด้วย "Windows Server 2012 R2" โดยที่บริการ Active Directory ก็จะทำงานอยู่บน Windows Server
และเนื่องจาก Active Directory เองก็มีการทำงานอยู่ด้วย ในด้านของความเข้ากันได้จึงถือว่าดีที่สุดในบรรดา directory type ทั้ง 3 ประเภท
อย่างไรก็ตาม ก็มีข้อจำกัดบางอย่างเมื่อเทียบกับ Active Directory ของ on-premises
ข้อจำกัดในการเชื่อมต่อกับ Active Directory ที่มีอยู่แล้ว เช่น on-premises AD เป็นต้น
- ไม่สามารถเพิ่ม AWS Managed Microsoft AD เป็น "Domain Controller เพิ่มเติม" ให้กับโดเมนเดิมที่มีอยู่ อย่างเช่น on-premises AD เป็นต้น
- ไม่สามารถเพิ่ม Domain Controller อย่างเช่น on-premises AD ให้กับโดเมนที่สร้างโดย AWS Managed Microsoft AD
ด้วยข้อจำกัดเหล่านี้ หมายความว่า "โครงสร้างที่เป็นการรวมกันของ Domain Controller อย่างเช่น on-premises AD กับ AWS Managed Microsoft AD จะไม่สามารถทำงานภายในโดเมนเดียวกันได้"
แต่ก็สามารถใช้งานได้ด้วย "การตั้งค่าความสัมพันธ์ที่เชื่อถือได้ระหว่าง AWS Managed Microsoft AD และ on-premises AD " แทนได้
ข้อจำกัดในการจัดการ Active Directory
- ผู้ใช้ที่ดูแลระบบโดเมน "Administrator" จะอยู่ภายใต้การควบคุมของ AWS และผู้ใช้ AWS ทั่วไปจะไม่สามารถใช้งาน Administrator ได้
(แต่หากมีผู้ใช้งานที่เป็น "Admin" จะสามารถใช้งานเป็นผู้ใช้ที่ดูแลระบบแทนได้) -
OU/container ของ AD directory (ตัวอย่างเช่น "Computers", "Domain Controller", "Users" เป็นต้น) จะอยู่ภายใต้การควบคุมของ AWS และผู้ใช้ AWS จะไม่สามารถย้ายหรือสร้าง object ใหม่ภายใน OU/container เหล่านี้ได้
(มี OU สำหรับผู้ใช้งาน AWS อยู่แล้ว โดยจะสร้าง object หรือ OU ย่อยที่จำเป็นใน OU นั้นๆ)
ข้อจำกัดเหล่านี้อาจไม่ส่งผลร้ายแรงมากนัก อย่างไรก็ตาม ควรคำนึงถึงว่าแนวทางและขั้นตอนการปฏิบัติงานในสภาพแวดล้อม Active Directory ที่มีอยู่อาจไม่สามารถนำมาใช้ได้อย่างสมบูรณ์
สัดส่วนของจำนวนผู้ใช้งานที่รองรับ
AWS Managed Microsoft AD สามารถเลือกได้จาก 2 "Edition"ตามรายละเอียดแต่ละรุ่นดังต่อไปนี้
| Edition/th> | จำนวนผู้ใช้งาน/objectที่รองรับ (โดยประมาณ) | ค่าบริการ (ข้อมูลอ้างอิง) |
|---|---|---|
| Standard Edition | สูงสุดที่ 5,000 ผู้ใช้งาน หรือ 30,000 object | 0.142 USD/ชั่วโมง |
| Enterprise Edition | สูงสุดที่ 500,000 object | 0.496 USD/ชั่วโมง |
※ ค่าบริการนี้เป็นราคาสำหรับ singapore region ณ เวลาที่เขียน (2023/08/24) โดยราคานี้เป็นราคาสำหรับค่าเริ่มต้น "Domain Controller x 2" และจะมีค่าบริการเพิ่มเมื่อมีการเพิ่ม Domain Controller
ราคา | AWS Directory Service | Amazon Web Services (AWS)
Simple AD
"Simple AD" เป็นบริการ managed service ที่ใช้ "Samba" ซึ่งมีความเข้ากันได้กับ Microsoft Active Directory ฟังก์ชันพื้นฐาน เช่น การจัดการผู้ใช้งาน, คอมพิวเตอร์ รวมไปถึงการตรวจสอบสิทธิ์การเข้าสู่ระบบ จะสามารถใช้งานได้ในลักษณะเดียวกับ Active Directory แต่ฟังก์ชันที่ Simple AD สามารถใช้งานได้ยังมีข้อจำกัดเมื่อเทียบกับฟังก์ชันต่างๆที่สามารถใช้งานได้ใน Active Directory
ฟังก์ชันที่ Simple AD ไม่รองรับ
Simple AD ไม่รองรับฟังก์ชันต่อไปนี้ใน Active Directory
- ความสัมพันธ์ที่เชื่อถือกันระหว่าง domain
- การขยาย LDAP schema
- ฟังก์ชัน "ถังขยะ"ของ Active Directory
- บัญชีบริการที่มีการจัดการกลุ่ม (gMSA)
- การตรวจสอบสิทธิ์แบบสองปัจจัยโดยใช้เซิร์ฟเวอร์ ของ RADIUS (MFA)
- จัดการโดยใช้เครื่องมือดังต่อไปนี้
- PowerShell
- "Active Directory Management Center" ที่ให้บริการตั้งแต่ Windows Server 2008 R2 เป็นต้นไป
(*เครื่องมือจัดการ Active Directory ที่ใช้มาตั้งแต่เดิมสามารถใช้งานได้)
นอกจากจะไม่สนับสนุน "ความสัมพันธ์ที่เชื่อถือกันระหว่าง domain" ในข้อแรกแล้ว ฟังก์ชันอย่างเช่น "การเพิ่มเป็น Domain Controller ที่มีอยู่", "การเพิ่มเป็น Domain Controller ที่มีอยู่ไปยัง domain ของ Simple AD" ก็จะไม่สามารถใช้งานได้เหมือนกับ AWS Managed Microsoft AD เช่นกัน
ดังนั้น ในทางปฏิบัติ Simple AD จะนำไปใช้ในลักษณะเป็น Active Directory domain ที่เป็นอิสระที่ไม่มีการเชื่อมโยงกับ on-premises AD
ประเภทของทรัพยากร AWS ที่สามารถเชื่อมโยงได้มีน้อย
ตามที่อธิบายไว้ในหัวข้อ "การใช้งาน AWS Directory Service" ว่ามีหลายบริการของ AWS ที่สามารถใช้ AWS Directory Service สำหรับจัดการและยืนยันผู้ใช้งานได้
โดยบริการของ AWS ทั้ง 10 รายการที่อยู่ใน "การใช้งาน AWS Directory Service" จะรองรับการเชื่อมโยงกับ AWS Managed Microsoft AD ทั้งหมด
แต่จะมีเฉพาะ "Amazon Connect", "Amazon WorkDocs", "Amazon WorkMail", "Amazon WorkSpaces" และ "AWS Client VPN" เท่านั้นที่สามารถเชื่อมโยงได้กับ Simple AD
นอกจากนี้ ในการลงชื่อเข้าใช้ AWS Simple AD ก็รองรับการเชื่อมโยงกับ Management Console แต่จะไม่รองรับการเชื่อมโยงกับ AWS SSO
สัดส่วนของจำนวนผู้ใช้งานที่รองรับ
Simple AD สามารถเลือก "SIZE" ได้ 2 แบบตามรายละเอียดดังต่อไปนี้
| SIZE | จำนวนผู้ใช้งาน/objectที่รองรับ (โดยประมาณ) | ค่าบริการ (ข้อมูลอ้างอิง) |
|---|---|---|
| Small | ผู้ใช้งานสูงสุดที่ 500 ผู้ใช้งาน หรือ 2,000 object | 0.08 USD/ชั่วโมง |
| Large | ผู้ใช้งานสูงสุดที่ 5,000 ผู้ใช้งาน หรือ 20,000 object | 0.24 USD/ชั่วโมง |
※ ค่าบริการนี้เป็นราคาสำหรับ singapore region ณ เวลาที่เขียน (2023/08/24)
Other Directory Types Pricing (English)
AD Connector
"AD Connector" เป็น directory type ที่มีแนวคิดแตกต่างจาก AWS Managed Microsoft AD และ Simple AD
โดย AD Connector จะไม่มีฐานข้อมูลเป็น Directory Service ของตนเองแต่จะมีฟังก์ชันในการเชื่อมโยงไปยัง Active Directory ที่มีอยู่ อย่างเช่น on-premises AD เป็นต้น
โดยวัตถุประสงค์หลักของการใช้ AD Connector คือการใช้ Active Directory ที่มีอยู่แล้ว เช่น on-premises AD สำหรับการจัดการและยืนยันผู้ใช้งานบริการของ AWS
ด้วยข้อยกเว้นบางประการของ FSx for Windows File Server บริการของ AWS สามารถเชื่อมโยงได้กับ "AWS Directory Service" เท่านั้น และไม่สามารถเชื่อมโยงได้โดยตรงกับ Active Directory ที่มีอยู่ได้
อย่างไรก็ตาม ด้วยการสอดแทรก "AD Connector" ซึ่งเป็น component ของ "AWS Directory Service" เข้าไประหว่าง Active Directory ที่มีอยู่แล้ว กับบริการ AWS จะทำให้สามารถเชื่อมโยงกับ Active Directory ที่มีอยู่โดยผ่าน AD Connector ได้
ถึงจะกล่าวกันว่า "AD Connector ทำหน้าที่เป็น "proxy" สำหรับ Active Directory ที่มีอยู่" แต่ AD Connector ก็จะไม่แคชข้อมูลใดๆของ Active Directory ทั้งสิ้น โดยจะทำงานเป็นการส่งต่อคำขอและการตอบกลับจากบริการของ AWS ไปยัง Active Directory เท่านั้น
ดังนั้นหากเครือข่ายระหว่าง AWS และสภาพแวดล้อม on-premises เกิดความล้มเหลวการยืนยันผู้ใช้งานจะไม่สามารถทำงานได้
สัดส่วนของจำนวนผู้ใช้งานที่รองรับ
AD Connector สามารถเลือก "SIZE" ได้ 2 แบบตามรายละเอียดดังต่อไปนี้
| SIZE | จำนวนผู้ใช้งาน/objectที่รองรับ (โดยประมาณ) | ค่าบริการ (ข้อมูลอ้างอิง) |
|---|---|---|
| Small | ออกแบบมาสำหรับองค์กรขนาดใหญ่ มีวัตถุประสงค์เพื่อจัดการการทำงานจำนวนเล็กน้อยต่อวินาที |
0.08 USD/ชั่วโมง |
| Large | ออกแบบมาสำหรับองค์กรขนาดเล็ก มีวัตถุประสงค์เพื่อจัดการการทำงานจำนวนปานกลางถึงสูงต่อวินาที |
0.24 USD/ชั่วโมง |
※ ค่าบริการนี้เป็นราคาสำหรับ singapore region ณ เวลาที่เขียน (2023/08/24)
ซึ่งจะต่างกับ AWS Managed Microsoft AD และ Simple AD ตรงที่ไม่มีการระบุจำนวนที่เฉพาะเจาะจง เช่น จำนวนผู้ใช้งาน หรือ object ที่รองรับ
การเชื่อมโยงกับบริการของ AWS
ตารางต่อไปนี้จะแสดงข้อมูล "directory type" แต่ละประเภทที่รองรับและไม่รองรับบริการของ AWS ที่สามารถเชื่อมโยงกับ AWS Directory Service ได้
| AWS service | AWS Managed Microsoft AD | Simple AD | AD Connector | อ้างอิง |
|---|---|---|---|---|
| Amazon Chime | 〇 | × | 〇 | ※1 ※2 |
| Amazon Connect | 〇 | 〇 | 〇 | |
| Amazon FSx for Windows File Server | 〇 | × | × | ※3 |
| Amazon QuickSight | 〇 | × | 〇 | ※4 |
| Amazon RDS/Aurora | 〇 | × | × | ※5 |
| Amazon WorkDocs | 〇 | 〇 | 〇 | |
| Amazon WorkMail | 〇 | 〇 | 〇 | ※6 |
| Amazon WorkSpaces | 〇 | 〇 | 〇 | |
| AWS Client VPN | 〇 | 〇 | 〇 | |
| AWS Management Console | 〇 | 〇 | 〇 | |
| AWS Single Sign-On (SSO) | 〇 | × | 〇 | |
| AWS Transfer Family | 〇 | × | 〇 |
(※1) ในการเชื่อมโยงกับ AWS Directory Service ใน Chime จำเป็นต้องตรวจสอบ domain ขององค์กรและเปิดใช้งาน "Enterprise account"
(※2) AWS Directory Service ที่สามารถเชื่อมโยงกับ Chime ได้นั้นจะจำกัดเฉพาะการสร้างใน "Northern Virginia (us-east-1) Region" เท่านั้น
(※3) เมื่อทำการเชื่อมโยงกับ AD ที่จัดการด้วยตนเองด้วย FSx for Windows File Server จำเป็นต้องเชื่อมโยงโดยตรงโดยไม่ต้องใช้ AD Connector
(※4) ในการเชื่อมโยงกับ AWS Directory Service ใน QuickSight จำเป็นต้องใช้ QuickSight Enterprise Edition
(※5) database engine หรือ เวอร์ชั่นของ RDS/Aurora บางตัวที่ไม่รองรับการเชื่อมโยงกับ AWS Directory Service
(※6) WorkMail เป็นบริการที่สามารถใช้งานได้เฉพาะ "Northern Virginia (us-east-1)", Oregon (us-west-2) และIreland (eu-west-1) เท่านั้น ในการเชื่อมโยงกับ AWS Directory Service จำเป็นต้องสร้างใน Region เดียวกับ WorkMail ด้วย
AWS Managed Microsoft AD รองรับบริการของ AWS ทั้งหมด และ AD Connector จะรองรับบริการเกือบทั้งหมดของ AWS
"FSx for Windows File Server" ไม่รองรับ AD Connector แต่ตามที่กล่าวไว้ในหมายเหตุว่า สามารถเชื่อมโยงได้โดยตรงกับ "AD ที่จัดการด้วยตนเอง" (อย่างเช่น on-premises AD)
"RDS" หรือ "Aurora" ไม่รองรับ AD Connector และไม่มีวิธีเชื่อมโยงกับ on-premises AD ได้โดยตรง
หากต้องการทำการยืนยันผู้ใช้งานโดยใช้ on-premises AD ด้วย RDS/Aurora หลังจากที่ตั้งค่า "ความสัมพันธ์ที่เชื่อถือได้" ระหว่าง AWS Managed Microsoft AD และ on-premises AD แล้ว แนะนำให้พิจารณาเชื่อมโยง RDS/Aurora กับ AWS Managed Microsoft AD
ตามที่อธิบายไว้ในหัวข้อ"เกี่ยวกับ directory type " Simple AD มีประเภทการรองรับของ AWS ที่สามารถเชื่อมโยงได้น้อยกว่ามากเมื่อเทียบกับ directory ประเภทอื่นๆ
รูปแบบการสร้างสภาพแวดล้อม Active Directory บน AWS
จะแนะนำรูปแบบต่างๆ สำหรับการสร้างสภาพแวดล้อม Active Directory โดยใช้ AWS Directory Service
รูปแบบที่ยกมานี้อาจไม่ได้ครอบคลุมทั้งหมด แต่ก็คิดว่าถือเป็นรูปแบบที่เป็นตัวแทนได้
โดยสามารถใช้เป็นข้อมูลอ้างอิงเพื่อพิจารณาว่าควรเลือก directory type ใดของ AWS Directory Service หรือ ในการเชื่อมโยงกับ Active Directory ต้องใช้โครงสร้างแบบไหน
การนำเข้า "Simple AD" แบบเดี่ยว
เมื่อใช้ Simple AD จะมีข้อจำกัดต่อไปนี้ตามที่อธิบายไว้ในบท "เกี่ยวกับ directory type"
- ไม่สามารถเพิ่ม Simple AD เป็น Domain Controller ให้กับโดเมนเดิมที่มีอยู่ หรือเพิ่ม Domain Controller ที่มีอยู่ไปยังโดเมน Simple AD ได้
-
ไม่สามารถตั้งค่า"ความสัมพันธ์ที่เชื่อถือได้"ระหว่าง Simple AD และ โดเมนเดิมที่มีอยู่ได้
ดังนั้น การใช้ Simple AD จะมีโครงสร้างอย่างเดียวคือ "นำไปใช้ในลักษณะเป็น Active Directory domain ที่เป็นอิสระที่ไม่มีการเชื่อมโยงกับ on-premises AD"
Use case สำหรับการใช้งาน Simple AD จะเป็นตามหัวข้อ "การยืนยัน,จัดการผู้ใช้งานเมื่อลงชื่อเข้าใช้ AWS "
หากไม่มีปัญหาในการจัดการผู้ใช้งานที่ใช้บริการของ AWS แยกจาก on-premises AD หรือหากไม่ได้ใช้งาน on-premises AD อยู่แล้ว การกำหนดค่าโดยใช้ Simple AD จึงเป็นตัวเลือกที่เรียบง่ายและต้นทุนต่ำที่สุด
นอกจากนี้ยังสามารถใช้งาน Simple AD ได้ใน Use case ดังต่อไปนี้
- ต้องการจัดการ Windows server ของ EC2 instances ในโดเมนของ Simple AD
-
ต้องการจัดการ client และผู้ใช้งานของสภาพแวดล้อม on-premises ในโดเมนของ Simple AD (สภาพแวดล้อม on-premises และ AWS ต้องเชื่อมต่อกันผ่าน DirectConnect หรือ Site-to-site VPN)
อย่างไรก็ตาม ก็ต้องพิจารณาเกี่ยวกับข้อจำกัดในฟังก์ชันที่เข้ากันได้กับ Active Directory ซึ่งสามารถใช้งานได้กับ Simple AD และแบนด์วิดท์เครือข่ายและปัญหาความล้มเหลวของเครือข่ายในกรณีมีเป้าหมายในการจัดการโดเมนในสภาพแวดล้อม on-premises
การนำเข้า "AWS Managed Microsoft AD" แบบเดี่ยว
นี่คือโครงสร้างที่เรียบง่ายที่สุดในการใช้งาน AWS Managed Microsoft AD
รูปแบบโครงสร้างนี้เป็นการแทนที่ "Simple AD" ด้วย "AWS Managed Microsoft AD" ในรูปแบบโครงสร้างของ Simple AD เท่านั้น
โดย Use case สำหรับการใช้งานก็ค่อนข้างจะเหมือนกับรูปแบบโครงสร้าง Simple AD แต่มีเหตุผลในการเลือก AWS Managed Microsoft AD แทน Simple AD ดังนี้
- ต้องการใช้บริการ AWS ที่ไม่รองรับการเชื่อมโยงกับ Simple AD
(อย่างเช่น「Amazon Chime」「Amazon QuickSight」เป็นต้น) - ต้องการใช้ฟังก์ชัน Active Directory ที่ไม่สามารถใช้งานได้ใน Simple AD
(อย่างเช่น ฟังก์ชัน「ถังขยะ」ของ Active Directory เป็นต้น) - ในแง่ของจำนวนผู้ใช้งาน และ ปริมาณของ object และเสปคของ Simple AD อาจไม่เพียงพอ
นอกจากนี้ ยังมี Use case ที่มีรูปแบบการใช้งานการยืนยันผู้ใช้ AWS Managed Microsoft AD เมื่อ EC2 instances ทำการเข้าถึง "RDS/Aurora"
เมื่อเปรียบเทียบกับวิธียืนยันผู้ใช้งานมาตรฐานของ RDS/Aurora (ชื่อผู้ใช้/รหัสผ่าน) การยืนยันผู้ใช้งานของ Active Directory จะมีความปลอดภัยมากกว่า เนื่องจากไม่ต้องการการจัดการรหัสผ่านบนเซิร์ฟเวอร์ใดๆ
การเชื่อมต่อไปยัง on-premises AD ด้วย "AD Connector"
จากนี้ไป จะเป็นรูปแบบการเชื่อมโยงทำงานร่วมกับ Active Directory ในสภาพแวดล้อมของ on-premises
นี่คือโครงสร้างที่เรียบง่ายที่สุดในบรรดารูปแบบการเชื่อมโยงกับ on-premises AD
ตามที่อธิบายไว้ในบท "เกี่ยวกับ directory type" บริการของ AWS จะไม่สามารถเชื่อมโยงกับ Active Directory ที่มีอยู่ได้โดยตรง เช่น on-premises AD
ในกรณีเช่นนี้ ด้วยการใช้ AD Connector บริการของ AWS จะสามารถเชื่อมโยงกับ AD ที่มีอยู่ได้
นอกจากจะใช้การเชื่อมโยงบริการของ AWS เข้ากับ AD ที่มีอยู่แล้ว AD Connector ยังสามารถใช้การเชื่อมโยง EC2 instance เข้ากับ AD ที่มีอยู่แล้วได้อีกด้วย (การเข้าร่วมโดเมนและการยืนยันการเข้าระบบสามารถจะทำได้กับ AD Connector ที่เชื่อมต่อกับ AD ที่มีอยู่แล้ว)
อย่างไรก็ตาม เนื่องจาก EC2 instance สามารถเชื่อมโยงกับ AD ที่มีอยู่ได้โดยตรงโดยไม่ต้องใช้ AD Connector จึงไม่สามารถใช้ AD Connector เพื่อจุดประสงค์ดังกล่าวได้
ตั้งค่าความสัมพันธ์ที่เชื่อถือได้ระหว่าง on-premises AD กับ "AWS Managed Microsoft AD"
ในรูปแบบโครงสร้างนี้ จะสร้าง AWS Managed Microsoft AD ที่เป็น "โดเมนที่แยกต่างจาก on-premises AD" บนฝั่ง AWS ก่อน (AWS Managed Microsoft AD จะไม่สามารถสร้างโดเมนเดียวกันกับ AD ที่มีอยู่ได้ ดังนั้นจึงต้องสร้างโดเมนอื่นแยก)
และทำการตั้งค่า “ความสัมพันธ์ที่เชื่อถือได้” ระหว่าง on-premises AD และ AWS Managed Microsoft AD
"ความสัมพันธ์ที่เชื่อถือได้" คือความสัมพันธ์ระหว่างโดเมน โดยที่โดเมนใดโดเมนหนึ่ง "เชื่อถือ" อีกโดเมนหนึ่ง ทำให้ผู้ใช้ที่ได้รับการยืนยันในโดเมนหนึ่งสามารถเข้าถึงเนื้อหาในอีกโดเมนอื่นได้
"ความสัมพันธ์ที่เชื่อถือได้" จะมี "ทิศทาง" ซึ่งประกอบด้วย"ความสัมพันธ์ความไว้วางใจแบบสองทาง" ซึ่งโดเมนต่าง ๆ ไว้วางใจซึ่งกันและกัน และความสัมพันธ์ความไว้วางใจแบบ"ทิศทางเดียว" ซึ่งโดเมนหนึ่งไว้วางใจอีกโดเมนหนึ่งฝ่ายเดียว
โดยในแต่ละประเภทบริการของ AWS มีทั้งบริการที่ต้องการความสัมพันธ์ที่เชื่อถือได้ "สองทาง" และบริการที่ใช้เพียงความสัมพันธ์ที่เชื่อถือได้ "ทางเดียว"
- ต้องใช้ความเชื่อถือสองทาง
- Amazon Chime
- Amazon Connect
- Amazon QuickSight
- Amazon WorkDocs
- Amazon WorkMail
- Amazon WorkSpaces
- AWS Client VPN
- AWS Management Console
- AWS Single Sign-On (SSO)
- AWS Transfer Family
- ต้องใช้ความเชื่อถือสองทาง หรือ ทางเดียว (AWS→on-premises)
- Amazon EC2 (การเพิ่มโดเมน・การยืนยันการเข้าใช้งาน)
- Amazon FSx for Windows File Server
- Amazon RDS/Aurora
แม้ว่าการเข้าถึงข้ามโดเมนสามารถทำได้ผ่านความสัมพันธ์ที่เชื่อถือได้ของโดเมน แต่ต้องจำไว้ว่าโดเมนนั้นจะแยกออกจากกันและข้อมูล เช่น ผู้ใช้และออบเจ็กต์ได้รับการจัดการในแต่ละโดเมน
กำหนดองค์ประกอบโดเมน Active Directory ด้วย on-premises AD และ "AD on EC2"
จะไม่สร้างโดเมนแยกกันบนฝั่ง on-premise หรือฝั่ง AWS โดยจะเป็นโครงสร้างที่ใช้งานโดเมนร่วมกันทั้งสองฝ่าย
แต่ว่าเนื่องจากไม่สามารถใช้งาน AWS Directory Service ในโครงสร้างนี้ได้ จึงต้องติดตั้ง Active Directory ไปยัง Windows Server ของ EC2 instance และสร้าง domain controller
และด้วยโครงสร้างนี้ไม่ได้ใช้บริการ Managed service ของ AWS Directory Service จึงต้องใช้เวลาและต้นทุนในการจัดการ EC2 instance ของ domain controller ด้วย
ข้อดีของการเลือกโครงสร้างนี้คือ การวาง domain controller ของโดเมนนึงไปไว้ที่ฝั่ง on-premises และฝั่ง AWS ซึ่งจะทำให้การประมวลผลสามารถดำเนินได้อย่างต่อเนื่องโดยใช้ AD ทางฝั่ง AWS ในกรณีที่เกิดความผิดพลาดใน AD ในฝั่ง on-premises
และถึงแม้ AD ในฝั่ง on-premises จะไม่สามารถกู้คืนได้เนื่องจากความล้มเหลวก็ตาม AD ก็ยังสามารถกู้คืนได้โดยการใช้ข้อมูลที่จำลองจาก domain controller ในฝั่ง AWS
กล่าวอีกนัยหนึ่งคือ นอกจากวัตถุประสงค์ในการใช้ฟังก์ชันต่างๆ เช่น การยืนยันโดเมนจาก AWS ที่เชื่อมโยงกับ on-premises AD แล้ว ยังรวมถึงการสำรองข้อมูลและ DR ของ on-premises AD ด้วย
อนึ่ง การสร้าง domain controller ด้วย EC2 instance บริการของ AWS จะไม่สามารถเชื่อมโยงกับ AD ได้โดยตรง
และหากต้องการเชื่อมโยงบริการของ AWS กับ AD สามารถนำ AD Connector มาใช้เพื่อเชื่อมต่อกับ AD ได้
～～～
สุดท้ายนี้ เราจะทำการเปรียบเทียบรูปแบบโครงสร้าง 3 รูปแบบที่เชื่อมโยงกับ on-premises AD และสรุปข้อดีและข้อเสียของแต่ละโครงสร้างกัน
- การเชื่อมต่อกับ on-premises AD ด้วย "AD Connector"
- 〇 โครงสร้างเรียบง่าย
- × หาก on-premises AD เกิดความล้มเหลวหรือการสื่อสารระหว่าง on-premises และ AWS ไม่สามารถใช้งานได้ ก็ไม่สามารถดำเนินการใดๆได้
- ตั้งค่าความสัมพันธ์ที่เชื่อถือได้ระหว่าง on-premises AD กับ "AWS Managed Microsoft AD"
- 〇 แม้ว่าความล้มเหลวเกิดขึ้นใน on-premises AD หรือการสื่อสารระหว่าง on-premises และ AWS ไม่สามารถใช้งานได้ การประมวลผลแบบปิดของทางฝั่ง on-premises และฝั่ง AWS ก็สามารถดำเนินต่อไปได้ (ตัวอย่างเช่น สามารถเข้าถึงทรัพยากรของ AWS ได้จาก EC2 instance ที่เข้าร่วมโดเมนของ AWS Managed Microsoft AD)
- 〇 สามารถจัดการ on-premises AD และ AD ฝั่ง AWS แยกกันได้ในระดับหนึ่ง (มีประโยชน์หากต้องการกำหนดขอบเขตระหว่าง on-premises และ AWS)
- × เนื่องจากไม่ได้ทำการคัดลอกหรือกระจายข้อมูล on-premises AD ไปยัง AWS ดังนั้นจึงไม่สามารถใช้เป็นโครงสร้างสำหรับ การสำรองข้อมูล หรือ DR ได้
- กำหนดองค์ประกอบโดเมน Active Directory ด้วย on-premises AD และ "AD on EC2"
- 〇 แม้ว่าความล้มเหลวเกิดขึ้นใน on-premises AD หรือการสื่อสารระหว่าง on-premises และ AWS ไม่สามารถใช้งานได้ การประมวลผลแบบปิดของทางฝั่ง on-premises และฝั่ง AWS ก็สามารถดำเนินต่อไปได้ (ตัวอย่างเช่น สามารถเข้าถึงทรัพยากรของ AWS ได้จาก EC2 instance ที่เข้าร่วมในโดเมน)
- 〇 เนื่องจากมีโดเมน Active Directory เพียงโดเมนเดียว จึงสามารถการจัดการได้ราบรื่นและง่ายดาย
- 〇 สามารถทำการสำรองข้อมูลและ DR ได้ เนื่องจากโครงสร้างที่ซ้ำซ้อนที่มีการคัดลอกหรือกระจายข้อมูล on-premises AD ไปยัง AWS (แม้ว่า domain controller ของฝั่ง on-premises จะไม่สามารถกู้คืนได้เนื่องจากความล้มเหลวก็ตาม ก็ยังสามารถประมวลผลต่อได้โดยการกู้คืนข้อมูลที่มีการคัดลอกไว้ที่ฝั่ง AWS โดย on-premises AD ก็สามารถกู้คืนได้เช่นกัน)
- × เนื่องจากไม่ใช่ Managed service จึงจำเป็นต้องจัดการ EC2 instance ของ domain controller (การอัปเดตแพตช์ของ OS เป็นต้น)
ตามรายละเอียดข้างต้นจะเห็นได้ว่า มีรูปแบบโครงสร้างที่เป็นไปได้หลายรูปแบบสำหรับการเชื่อมโยงระหว่าง on-premises AD และ AWS โดยในแต่ละรูปแบบมีข้อดีและข้อเสียที่แตกต่างกันไป
ไม่มีรูปแบบโครงสร้างใดที่เหนือกว่าเสมอไป ดังนั้นจึงควรพิจารณารายละเอียดต่างๆ เช่น "จุดประสงค์ของการเชื่อมโยงกับ AD ในองค์กรคืออะไร" "ต้นทุน, ความน่าเชื่อถือ, การทำงาน หรือเรื่องใดๆที่ให้ความสำคัญ" หวังว่าจะมีประโยชน์ในการเลือกรูปแบบโครงสร้างกันครับ
บทความอ้างอิง
- Amazon WorkSpaces คืออะไร? การแนะนำฟังก์ชันของ AWS | DevelopersIO
- สร้าง File server ด้วย FSx for Windows File Server และ Directory Service(Microsoft AD) | DevelopersIO
